Research

Some folks just naturally push outside their comfort zones as a matter of course. I am one of them. Others only do things that are comfortable, which is fine if it works for them. I believe that while you are basically born with a certain risk tolerance, you can be taught to get comfortable with pushing past your comfort zone. For example, kids who are generally shy will remain more comfortable holding up the wall at a social event, but can learn to approach people and get into the mix. It’s tough at first but you figure it out. There is always resistance the first few times you push a child beyond what they are comfortable with, and force them to try something they don’t think they can do. But I believe it needs to happen. It comes back to my general philosophy that limitations exist only in our minds, and you can move past those limitations once you learn to face your fear. The twins’ elementary school does a drama production every year. XX1 was involved when she was that age, and XX2 was one of the featured performers last year. We knew that she’d be right there auditioning for the big role, and she’d likely get one of them (as she did). But with the Boy we weren’t sure. He did the hip hop performance class at camp so he’ll perform, but that’s a bit different than standing up and performing in front of your friends and classmates. Though last year he did comment on how many of his friends were in the show, and he liked that. We were pleased when he said he wanted to try out. The Boss helped him put together both a monologue and a song to sing for the audition. He knew all the words, but when it came time to practice he froze up. He didn’t want to do it. He wanted to quit. That was no bueno in my book. He needed to try. If he didn’t get a part, so be it. But he wasn’t going to back out because he was scared. He needed to push through that fear. It’s okay to not get the outcome you hope for, but not to quit. So we pushed him. There were lots of tears. And we pushed some more. A bit of feet stomping at that point. So we pushed again. He finally agreed to practice for us and then to audition after we wore him out. Sure, that was a little heavy-handed, but I’m okay with it because we decided he needed to at least try. The end result? Yes, he got a part. I’m not sure how much he likes the process of getting ready for the show. We’ll see once he gets up on stage and performs for everyone whether it’s something he will want to do again. But whether he does it again doesn’t matter. He can always say he tried, even when he didn’t want to. That he didn’t let fear stop him from doing something. And that’s the most important lesson of all. –Mike Photo credit: “Faces of fear!” originally uploaded by John Seb Barber The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the 2014 conference. You can check it out on YouTube. Take an hour and check it out. Your emails, alerts and Twitter timeline will be there when you get back. Securosis Firestarter Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and.. hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail. December 18 – Predicting the Past November 25 – Numbness October 27 – It’s All in the Cloud October 6 – Hulk Bash September 16 – Apple Pay August 18 – You Can’t Handle the Gartner July 22 – Hacker Summer Camp July 14 – China and Career Advancement June 30 – G Who Shall Not Be Named June 17 – Apple and Privacy May 19 – Wanted Posters and SleepyCon 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, with our content in all its unabridged glory. And you can get all our research papers too. Security Best Practices for Amazon Web Services Third Party Tools Built-in Features Introduction Network Security Gateway Evolution Introduction Monitoring the Hybrid Cloud: Evolving to the CloudSOC Migration Planning Technical Considerations Solution Architectures Emerging SOC Use Cases Introduction Security and Privacy on the Encrypted Network Selection Criteria and Deployment Use Cases The Future is Encrypted Newly Published Papers Securing Enterprise Applications Secure Agile Development Trends in Data Centric Security Leveraging Threat Intelligence in Incident Response/Management The Security Pro’s Guide to Cloud File Storage and Collaboration The 2015 Endpoint and Mobile Security Buyer’s Guide Open Source Development and Application Security Analysis Advanced Endpoint and Server Protection The Future of Security Incite 4 U Full discraposure: Google discovers a bug in a Microsoft product. Google has a strict 90-day policy to disclose, no matter what. Microsoft says, “Hey, we have a fix ready to go on Patch Tuesday, can we get a few extra days?” but Google releases anyway. I’m sorry, but who does that help? Space Rogue summed it up best; he has a long history in the disclosure debate. In his words, “The entire process has gotten out of hand. The number one goal here should be getting stuff fixed because getting stuff fixed helps protect the user, it helps defeat the bad guys and it helps make the world a better place.” Another great quote is: “And so the disclosure debate continues unabated for over a hundred years. With two of the giants in our industry acting like spoiled children we as security professionals must take the reigns

Early December is a big deal in our house. It’s Nutcracker time, with both girls working all fall to get ready for their dance company’s annual production of the Xmas classic. They do 5 performances over a weekend, and neither girl wants it to end. We have to manage the letdown once that weekend is over. It has been really awesome to see all of the dancers grow up, via the Nutcracker. They start as little munchies playing party boys and girls in the first scene, and those who stick with it become Dew Drop or possibly even the Sugarplum Fairy. The big part for XX1’s group this year was Party Clara. It’s on Pointe and it’s a big and featured role in Act 1. She has been dreaming about this part for the past 4 years, and when we heard she got it for one of the performances this year, we knew it was going to be a special Nutcracker. She also got a featured Rag Doll part for another performance and was on stage 4-5 times during the show. XX2 wasn’t left out, and she got a number of featured parts as well. I used to dread that weekend but the girls didn’t really do much, so I could get away with going to one performance and being done with it. Now I attend 3 out of the 5 performances, and would go to all 5 if the girls had sufficient parts. I’m pretty sure the Boy wouldn’t be happy going to 5 performances, but he’ll get over it. I even skipped a home Falcons game to see the Sunday afternoon performance (I did!). One of the things I am working on is to pause during the big stuff and just enjoy it. You could call it smelling the flowers or something like that. For me it’s about savoring the moment. To see XX1 with a grin ear to ear performing as Party Clara was overwhelming for me. She was so poised, so in command, so happy. It was incredible. During those 3-4 minutes the world fell away. There was only my girl on stage. That’s it. Some folks watch their kids perform through a camera viewfinder. Or a cellphone screen while taking video. Not me. I want to experience it directly through my own eyes. To immerse myself in the show. I want to imprint it in my memory. Yes, we’ll buy the DVD of the performance, but that’s for the folks who weren’t there. I don’t need it. I was fully in that moment, and I can go back any time I want. And I do. –Mike Photo credit: “P1-VS-P2” originally uploaded by MoreInterpretations The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the 2014 conference. You can check it out on YouTube. Take an hour and check it out. Your emails, alerts and Twitter timeline will be there when you get back. Securosis Firestarter Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and.. hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail. December 18 – Predicting the Past November 25 – Numbness October 27 – It’s All in the Cloud October 6 – Hulk Bash September 16 – Apple Pay August 18 – You Can’t Handle the Gartner July 22 – Hacker Summer Camp July 14 – China and Career Advancement June 30 – G Who Shall Not Be Named June 17 – Apple and Privacy May 19 – Wanted Posters and SleepyCon 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, with our content in all its unabridged glory. And you can get all our research papers too. Security Best Practices for Amazon Web Services Third Party Tools Built-in Features Introduction Network Security Gateway Evolution Introduction Monitoring the Hybrid Cloud: Evolving to the CloudSOC Migration Planning Technical Considerations Solution Architectures Emerging SOC Use Cases Introduction Security and Privacy on the Encrypted Network Selection Criteria and Deployment Use Cases The Future is Encrypted Newly Published Papers Securing Enterprise Applications Secure Agile Development Trends in Data Centric Security Leveraging Threat Intelligence in Incident Response/Management The Security Pro’s Guide to Cloud File Storage and Collaboration The 2015 Endpoint and Mobile Security Buyer’s Guide Open Source Development and Application Security Analysis Advanced Endpoint and Server Protection The Future of Security Incite 4 U Security deadly sin: offensive envy: I dug up Richard Bejtlich’s awesome post from right before New Year, where he dismantles a list from Microsoft’s John Lambert and calls him out for minimizing the potential of defensive security. It is true that hacking stuff is sexy, and the chicks & dudes dig it. But still, the fact that many defenders work off checklists doesn’t mean all do. Because the defenders seem to come up on the losing end of some breach every day doesn’t mean their efforts are pointless. It means it’s a hard job, pure and simple. And glorifying the adversary only provides a defeatist attitude before you even start playing. Which I guess is the adversary’s plan… – MR No hands: I just love it when someone comes up with an entire class of security vulnerability – and if it might affect an Apple product guess what’s in the headlines? Like the general GSM wireless issue that was hyped as “iPhones Vulnerable” (every GSM phone was vulnerable). That hype sometimes does the issue a disservice, as highlighted in this piece at the Huffington Post on Jan Krissler recreating thumbprints from normal photographs at the Chaos Computer Club. It’s a fascinating and brilliant idea as we progress towards ubiquitous high-definition cameras throughout the world. Not merely for hacking phones, but for all the CSI-spinoff episodes it will inspire. Practically speaking,

Our Use Cases post ran through setting policies for decryption, and specific use cases driving decryption of network traffic. We also brought up human resources and compliance considerations when building policies. But that doesn’t address the technical nuances of actually figuring out where to decrypt, or how to select and deploy the technology, so here we go. First let’s talk a bit about whether you need a standalone device. Standalone or Integrated? Many network and security devices can terminate and decrypt network sessions – including firewalls, IPS, load balancers, UTM, and web & email security gateways. Obviously using an existing device is simpler, often the path of least resistance for decryption and inspection. You don’t have to add other boxes or risk messing up your network addressing scheme, and you can enforce policies right at the point of decryption/inspection. A security device can decrypt traffic, inspect it, apply policy, and re-encrypt – all within a single product. For environments with minimal network volumes and simple policies, integrated devices work well. But those who need to decrypt substantial network traffic tend to quickly crush the performance of existing security devices if they try to decrypt on existing devices. As we mentioned in our last post, onboard decryption may reduce performance of security devices by 33% to 80%. If you have plenty of performance headroom on your security devices that’s OK. If you don’t you need to look at another device to offload decryption load, in order to let your security devices do what they do best: inspect traffic, apply policies, and monitor or capture traffic. If you deploy complicated policies, such as multiple policy triggers across the entire network stream rather than limiting yourself to port 443 (HTTPS), an integrated device’s relatively simple decryption policies may be insufficient. Additionally, if you need to send decrypted traffic to multiple places, such as a SIEM or network packet capture device, an integrated solution may not be a good fit. We have nothing against the integrated option, but pragmatism and drives us toward the right tool for the job. If onboard decryption can meet your performance and policy requirements, do it. But if not you likely need a standalone decryption device. Selection Criteria Once you have decided to use a dedicated decryption device, what should you look for? Here are a few things to think about: Performance: Much of the value of dedicated hardware is its ability scale up with traffic volume. Make sure any device or devices you buy can scale to your current and future volumes. Don’t paint yourself into a corner by buying equipment that will need to be replaced when traffic volume grows. All Port Support: One of the easiest evasion techniques for attackers is to simply change the port number of their outbound traffic, sending encrypted traffic where it is not expected or monitored. Inspection devices cannot afford to trust port numbers – you need deep packet inspection looking at payloads to detect evasion. Accuracy: Decryption strategy is highly policy dependent, so success requires accurate categorization of traffic. Related to looking at the full traffic stream, you need to ensure your devices accurately find encrypted traffic and categorize it effectively. Policy actions: Once you have a policy hit, make sure your device supports a variety of different actions. You should be able to decrypt, not decrypt, drop the session, or reject the session (with a website failure code). You also want the ability to list sources or destinations as always decrypt (blacklist) or never decrypt (whitelist), by group or user. Website category/reputation support: A big chunk of our use case post talked about setting policies; they may include websites, IP addresses, and applications. Given how quickly website reputation and categories change (minutes – if not seconds), it is important to have a dynamic source of current information to base policies on. That usually means some kind of cloud-based website categorization service for whitelisting, along with dynamic reputation scoring for websites and applications. Multiple device support: Given the varied decryption use cases, these devices should be flexible in how they forward traffic, and to how many devices. For example you might want to send traffic to both an IPS for active control, and also a packet capture device for monitoring and forensics. It is also important for decryption devices to interoperates natively with security devices, so that (for instance) an IPS which detects decrypted attack traffic can drop that session without human intervention. Security: This is a security device, so you will want to ensure that decryption/resigning keys and data on the device are protected. You also want the ability to reject/drop sessions if their security is insufficient. For example a weak encryption cipher could data at risk; it might be forbidden to transmit encrypted data which cannot be decrypted by the security device, to prevent unknown data from leaving your environment. Transparency: It is also important to ensure decryption doesn’t impact application behavior or user interaction. End users should not need to concern themselves with security inspection. Further, the decryption device shouldn’t alter packet headers in any way, as that might impair other security devices’ inspection. Basically, nobody should know the device is there. Deployment flexibility: Decryption needs to be inserted into the flow of traffic, so you want a device that supports multiple deployment models, discussed below. For devices with multiple ports, you should have flexibility in assigning them to specific devices. You should also be able to apply policies both actively and passively. Deployment Decryption device deployment should be as non-disruptive as possible. You don’t want to mess around with IP addressing schemes, force every user to see a security warning every time they make an SSL connection, or have the device manipulate IP address headers and screw up your ability to monitor and analyze traffic. You want transparency, as mentioned above. Also make sure you are seeing all relevant traffic. Don’t make assumptions about what is relevant and what isn’t. Attackers frequently hide encrypted traffic on

In the first post of this series on Security and Privacy on the Encrypted Network, we argued that organizations need to encrypt more traffic. Unfortunately the inability to see and inspect encrypted traffic impairs the ability to enforce security controls/policies and meet compliance mandates. So let’s dig into how to strategically decrypt traffic in order to address a few key use cases – including enforcing security policies and monitoring for security and compliance. We also need to factor in the HR and privacy issues associated with decrypting traffic – you don’t want to end up on the wrong side of a worker council protesting your network security approach. What to Decrypt The first step in gaining visibility into the encrypted network is to set policies for when traffic will be decrypted and for how long. These decisions depend more on organizational culture than anything else, so you need to figure out what will work for your company. As security guys we favor more decryption than less, because that enables more comprehensive inspection… and therefore stronger monitoring and enforcement. But this is a company-specific choice. Several factors influence decryption policies, most obviously the applications themselves. Let’s briefly cover the main applications you are most likely to decrypt: Webmail: Employees think they are doing your organization a favor by working at all times of the day. But this always-on workforce requires use of personal devices, and may decide (however misguided) that it’s easiest to send work documents to personal machines via personal email accounts. What could go wrong? And of course there are more malicious uses for webmail in a corporate environment. There are endpoint DLP agents that should catch this behavior, but if you don’t have them deployed you should be inspecting outbound webmail traffic. The complication is that most webmail is now encrypted so you need to decrypt sessions to inspect the traffic. Web browsing: Similarly social media sites and other web properties utilize user-generated content that may be protected or sensitive, so you need to ensure you can enforce policies on web application traffic as well. Many apps use SSL/TLS by default, so you will need to decrypt to enforce acceptable use policies and protect data. SaaS Apps: Business functions are increasingly migrating to Software as a Service (SaaS) so it is important to inspect SaaS traffic. You may want to enforce tighter content policies on SaaS apps, but first you need to decrypt their traffic for inspection and enforcement. Custom Apps: Similarly your custom web apps (or partner web apps) require scrutiny given the likelihood that they will use sensitive data. As with SaaS apps, you will want to enforce granular policies for these apps, which requires decryption. To net it out, if an application has access to protected or critical data you should decrypt and inspect its traffic. Within each application defined above, secondary attributes may demand or preclude decryption. For example certain web apps/sites should be whitelisted because they handle private employee data, such as consumer healthcare and financial sites. Another policy trigger will be individual employees and groups. Maybe you don’t want to decrypt traffic from the legal team, because it is likely protected and sensitive. And of course there are the folks who require exceptions. Like the CEO, who gets to do whatever he/she wants and may approve an exception for their own traffic. There will be other exceptions (we guarantee it), so make sure your policies include the ability to selectively decrypt and enforce policies. For example one app may need to always be inspected (regardless of user) based on the sensitivity of data it can access. Likewise perhaps one set of users won’t have their traffic inspected at all. You should have flexibility to decrypt traffic to enforce policies, based on applications and users/groups, to accurately map to business processes and requirements. Regardless of the use case for decryption, you will want to be flexible about what gets decrypted, for whom, and when. Where to Decrypt? Now that you know what to decrypt you need to determine the best place to do it. This decision hinges on type of traffic (ingress vs. egress), which applications need to be inspected, and which devices you need to send data to for monitoring and/or enforcement. Firewall: Firewalls frequently take on the decryption role because they is inline for both egress and ingress, and already enforcing policies – especially as they evolve toward application-aware Next Generation Firewalls (NGFW). Unfortunately decryption is computationally demanding, which creates scaling issues even for larger and more powerful firewalls. IPS: IPS is an inspection technology, so an inability to inspect encrypted traffic is a serious limitation. To address this some organizations decrypt on their IPS devices. The IPS function is computationally demanding so these devices tend to have more horsepower, which helps when doing decryption. But as with firewalls, scalability can be an issue. Web filter: Due to their role, web filters need to decrypt traffic. They tend to be a bit underpowered compared to other devices in the DMZ, so unless there is minimal encrypted traffic, they can run out of gas quickly. Dedicated SSL decryption device: For organizations with a lot of encrypted traffic (which is becoming more common), a few dedicated decryption devices are available which specialize in decrypting traffic without disrupting employees, offering flexibility in how to route decrypted traffic for either active controls (FW, IPS, web filter, etc.) or monitoring, and then re-encrypting as it continues out to the Internet. We will get into specifics of selecting and deploying these devices in our next post. Cloud-based offerings: As Security as a Service (SECaaS) offerings mature, organizations have the option to decrypt in the cloud, removing their responsibility for scalability. On the other hand this requires potentially sensitive data to be decrypted and inspected in the cloud, which may be a cultural or regulatory challenge. These devices are typically deployed inside your network permiter, so you remain blind to attackers encrypting internal reconnaissance traffic, or traffic moving

Every so often the kids do something that makes me smile. Evidently the Boss and I are doing something right and they are learning from our examples. I am constantly amused by the huge personality XX2 has, especially when performing. She’s the drama queen, but in a good way… most of the time. The Boy is all-in on football and pretty much all sports – which of course makes me ecstatic. He is constantly asking me questions about players I’ve never heard of (thanks Madden Mobile!); he even stays up on Thursday, Sunday, and Monday nights listening to the prime-time game using the iPod’s radio in his room. We had no idea until he told me about a play that happened well after he was supposed to be sleeping. But he ‘fessed up and told us what he was doing, and that kind of honesty was great to see. And then there is XX1, who is in raging teenager mode. She knows everything and isn’t interested in learning from the experience of those around her. Very like I was as a teenager. Compared to some of her friends she is a dream – but she’s still a teenager. Aside from her independence kick she has developed a sense of humor that frequently cracks me up. We all like music in the house. And as an old guy I just don’t understand the rubbish the kids listen to nowadays. Twice a year I have to spend a bunch of time buying music for each of them. So I figured we’d try Spotify and see if that would allow all of us to have individual playlists and keep costs at a manageable level. I set up a shared account and we all started setting up our lists. It was working great. Until I was writing earlier this week, jamming to some new Foo Fighters (Sonic Highways FTW), and all of a sudden the playlist switched to something called Dominique by the Singing Nun. Then Spotify goes berserk and cycles through some hardcore rap and dance. I had no idea what was going on. Maybe my phone got possessed or something. Then it clicked – XX1 was returning the favor for all the times I have trolled her over the years. Yup, XX1 hijacked my playlist and was playing things she knew aren’t anywhere near my taste. I sent her a text and she confessed to the prank. Instead of being upset I was very proud. Evidently you can’t live with a prankster and not have some of that rub off. Now I have to start planning my revenge. But for the moment I will just enjoy the fact that my 14-year-old daughter still cares enough to troll me. I know soon enough getting any kind of attention will be a challenge. –Mike Photo credit: “Caution Troll Ahead” originally uploaded by sboneham The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the conference this year. You can check it out on YouTube. Take an hour and check it out. Your emails, alerts and Twitter timeline will be there when you get back. Securosis Firestarter Have you checked out our video podcast, The Firestarter? Rich, Adrian, and Mike get into a Google Hangout and.. hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail despite Adrian’s best efforts to keep us on track. November 25 – Numbness October 27 – It’s All in the Cloud October 6 – Hulk Bash September 16 – Apple Pay August 18 – You Can’t Handle the Gartner July 22 – Hacker Summer Camp July 14 – China and Career Advancement June 30 – G Who Shall Not Be Named June 17 – Apple and Privacy May 19 – Wanted Posters and SleepyCon May 12 – Another 3 for 5: McAfee/OSVDB, XP Not Dead, CEO head rolling 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, with our content in all its unabridged glory. And you can get all our research papers too. Network Security Gateway Evolution Introduction Monitoring the Hybrid Cloud: Evolving to the CloudSOC Migration Planning Technical Considerations Solution Architectures Emerging SOC Use Cases Introduction Security and Privacy on the Encrypted Network The Future is Encrypted Newly Published Papers Securing Enterprise Applications Secure Agile Development Trends in Data Centric Security Leveraging Threat Intelligence in Incident Response/Management The Security Pro’s Guide to Cloud File Storage and Collaboration The 2015 Endpoint and Mobile Security Buyer’s Guide Open Source Development and Application Security Analysis Advanced Endpoint and Server Protection The Future of Security Incite 4 U Flowing downhill: Breaches are ugly. Losing credit card numbers, in particular, can be costly. But after the PCI fines, the banks are always lurking in the background. When Target lost 40 million credit cards, and the banks needed to rotate card numbers and reissue, it isn’t like Target paid for that. And the card brands most certainly will never pay for that. No, they sit there, collect PCI fines (despite Target passing their assessment), and keep the cash. The banks were left holding the bag, and they are sure as hell going to try to get their costs covered. A group of banks just got court approval to move forward with a lawsuit to recover their damages from Target. They are seeking class action status. If the old TJX hack is any indication, they will get it and receive some level of compensation. Resolving all the costs of a breach like this plays out over years, and odds are we will no idea of the true costs for at least 5. Cloud security “grows up”? It’s funny when the hype machine wants to push something faster than it is ready to go. Shimmy argued that Cloud security grows up,

I really enjoyed Thom Langford’s recent post Three Envelopes, One CISO, on the old parable about preparing three envelopes to defer blame for bad things – until you cannot shift it, when you take the bullet. In the CISO’s case it is likely to be a breach. So first blame your predecessor, though I have found that only works for about 6 months. If you get that long a honeymoon, then by the time you have been in the seat for 6 months it is your problem. For the second breach, blame your team. Of course this is limiting – you need them to work for you, but it’s a question of survival at this point, right? When the third breach comes around, you prepare 3 new envelopes, because you are done. Though most folks only get one breach now – especially if they bungle the response. But that’s not Thom’s point, nor is it mine. He brings the discussion back around to the recent Sony breach. Everyone seems to want to draw and quarter a CISO for all sorts of ills. It may be well-deserved, but the rush to judgement doesn’t really help anything, does it? Especially now that it seems to have been a highly sophisticated attack, which Mandiant called ‘unprecedented’. So did the CISOs do themselves any favors? Probably not. But as Thom says, We seem to want to chop down the CISO as soon as something goes wrong, rather than seeing it in the context of the business overall. Let’s wait and see what actually happened before declaring his Career Is So Over, and also appreciate that security breaches are not always the result of poor information security, but often simply a risk taken by the business that didn’t pay off. And with that I open the second envelope Rich gave me when I started at Securosis… Photo credit: “tiny envelope set: radioactive flora” originally uploaded by Angela Share:

As I sit in yet another hotel, banging out yet another Incite, overlooking yet another city that isn’t home, this is a good time to look back on 2014 because this is my last scheduled trip for this year. It has been an interesting year. At this point the highs this year feel higher, and the lows lower. There were periods when I felt sick from the whiplash of ups and downs. That’s how life is sometimes. Of course my mindfulness practice helps me handle the turbulence with grace, and likely without much external indication of the inner gyrations. But in 5 years how will I look back on 2014? I have no idea. I have tried not to worry about things like the far future. At that point, XX1 will be leaving for college, the twins will be driving, and I’ll probably have the same amount of gray hair. Sure, I will plan. But I won’t worry. I have been around long enough to know that my plans aren’t worth firing the synapses to devise them. In fact I don’t even write ‘plans’ down any more. It is now December, when most of us start to wind down the year, turning our attention to the next. We are no different at Securosis. For the next couple weeks we will push to close out projects that have to get done in 2014 and start working with folks on Q1 activities. Maybe we will even get to take some time off over the holidays. Of course vacation has a rather different meaning when you work for yourself and really enjoy what you do. But I will slow down a bit. My plan is to push through my handful of due writing projects over the next 2 weeks or so. I will continue to work through my strategy engagements. Then I will really start thinking about what 2015 looks like. Though I admit the slightly slower pace has given me opportunity to be thankful for everything. Certainly those higher highs, but also the lower lows. It’s all part of the experience I can let make me crazy, or I can accept bumps as part of the process. I guess all we can do each year is try to grow from every experience and learn from the stuff that doesn’t go well. For better and worse, I learned a lot this year. So I am happy as I write this although I know happiness is fleeting – so I’ll enjoy the feeling while I can. And then I will get back to living in the moment – there really isn’t anything else. –Mike Photo credit: “wind-up dog” originally uploaded by istolethetv The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the conference this year. You can check it out on YouTube. Take an hour and check it out. Your emails, alerts and Twitter timeline will be there when you get back. Securosis Firestarter Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and.. hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail. November 25 – Numbness October 27 – It’s All in the Cloud October 6 – Hulk Bash September 16 – Apple Pay August 18 – You Can’t Handle the Gartner July 22 – Hacker Summer Camp July 14 – China and Career Advancement June 30 – G Who Shall Not Be Named June 17 – Apple and Privacy May 19 – Wanted Posters and SleepyCon May 12 – Another 3 for 5: McAfee/OSVDB, XP Not Dead, CEO head rolling 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, with our content in all its unabridged glory. And you can get all our research papers too. Network Security Gateway Evolution Introduction Monitoring the Hybrid Cloud: Evolving to the CloudSOC Technical Considerations Solution Architectures Emerging SOC Use Cases Introduction Security and Privacy on the Encrypted Network The Future is Encrypted Newly Published Papers Securing Enterprise Applications Secure Agile Development Trends in Data Centric Security Leveraging Threat Intelligence in Incident Response/Management The Security Pro’s Guide to Cloud File Storage and Collaboration The 2015 Endpoint and Mobile Security Buyer’s Guide Open Source Development and Application Security Analysis Advanced Endpoint and Server Protection The Future of Security Incite 4 U CISO in the clink… I love this headline: Can a CISO serve jail time? Duh, of course they can. If they deal meth out of the data center, they can certainly go to jail. Oh, can they be held accountable for breaches and negligence within their organization? Predictably, the answer is: it depends. If you are clearly negligent then all bets are off. But if you act in the best interests of the organization as you see them … it is hard to see how a CISO could be successfully prosecuted. That said, there is a chance, so you need to consult a lawyer before taking the job to understand where your liability begins and ends (based on your agreement), and then you can make an informed decision on whether to take the job. Or at least build some additional protection into your agreement. – MR Productivity Killer: Sometimes we need a reminder that security isn’t all about data breaches and DDoS. Sometimes something far far worse happens. Just ask Sony Pictures. Last week employees showed up to work to find their entire infrastructure compromised and offline. Yep, down to some black hat hax0rs graphic taking over everyone’s computer screens, just like in… er… the movies. I don’t find any humor in this. Despite what Sony is doing to the Spider-Man franchise, they are just a company with people trying to get their jobs done, make a little scratch, and build products

Interruption is death for a writer. At least it is for me. I need to get into a flow state, where I’m locked in and banging words out. With my travel schedule and the number of calls I make even when not traveling, finding enough space to get into flow has been challenging. Very challenging. And it gets frustrating. Very frustrating. There is always some shiny object to pay attention to. A press release here. A tweet fight there. Working the agenda for a trip two weeks from now. Or something else that would qualify as ‘work’, but not work. Then achiever’s anxiety kicks in. The blog posts that get pushed back day after day, and the conflicts with projects needing to get started. I have things to do, but they don’t seem to get done. Not the writing stuff anyway. It’s a focus thing. More accurately a lack of focus thing. Most of the time I indulge my need to read NFL stories or do some ‘research’. Or even just to think big thoughts for a little while. But at some point I need to write. That is a big part of the business, and stuff needs to get done. So I am searching for new ways to do that. I shut down email. That helps a bit. I don’t answer the phone and don’t check Twitter. That helps too. Maybe I will try a new writing app that basically shuts down all the other apps. Maybe that will help ease the crush of the overwhelming to-do list. Of course my logical mind knows you just start writing. That I need to stop with the excuses and just write. I know the first draft is going to be crap, especially if it’s not flowing. I know that the inbound emails can wait a few hours. I know my Twitter timeline will be there after the post is live on the site. Yet my logical mind loses, as I just stare at the screen for a few more minutes. Then check email and Twitter. Again. Oy. Then I go into my pipeline tracker and start running numbers for the impact of not writing on my wallet. That helps. Until it doesn’t. We have had a good year, so the monkey brain wonders whether it’s not really a bad idea to just sandbag some of the projects and get 2015 off to a roaring start. But I still need to write. Then at some point, I just write. The excuses fall away. The words start to flow, and even make some sense. I get laser focused on the research that needs to get done, and it gets done. The blog fills up with stuff, and balance is restored to my universe. And I resign myself to just carrying around my iPad when I really need to write, because it’s harder to multi-task on that platform. I’ll get there. It’ll just take a little focus. –Mike Photo credit: “Focus” originally uploaded by Michael Dales The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the conference this year. You can check it out on YouTube. Take an hour and check it out. Your emails, alerts and Twitter timeline will be there when you get back. Securosis Firestarter Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and.. hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail. October 27 – It’s All in the Cloud October 6 – Hulk Bash September 16 – Apple Pay August 18 – You Can’t Handle the Gartner July 22 – Hacker Summer Camp July 14 – China and Career Advancement June 30 – G Who Shall Not Be Named June 17 – Apple and Privacy May 19 – Wanted Posters and SleepyCon May 12 – Another 3 for 5: McAfee/OSVDB, XP Not Dead, CEO head rolling 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, with our content in all its unabridged glory. And you can get all our research papers too. Network Security Gateway Evolution Introduction Monitoring the Hybrid Cloud: Evolving to the CloudSOC Emerging SOC Use Cases Introduction Building an Enterprise Application Security Program Recommendations Security Gaps Use Cases Introduction Security and Privacy on the Encrypted Network The Future is Encrypted Newly Published Papers Secure Agile Development Trends in Data Centric Security Leveraging Threat Intelligence in Incident Response/Management The Security Pro’s Guide to Cloud File Storage and Collaboration The 2015 Endpoint and Mobile Security Buyer’s Guide Open Source Development and Application Security Analysis Advanced Endpoint and Server Protection The Future of Security Incite 4 U Master of the Obvious: Cloud Edition: On my way to the re:Invent conference I read the subhead of a FUD-tastic eWeek article: IT Losing the Battle for Security in the Cloud, which is “More than two-thirds of respondents to a Ponemon Institute survey say it’s more difficult to protect sensitive data in the cloud using conventional security practices.” Um. This is news? The cloud is different! So if you want to secure it you need to do so differently. The survey really shows that most folks have no idea what they are talking about, expected in the early adoption phase of any technology. It is not actually necessarily harder to protect resources in the cloud. I just laugh and then cry a bit, as I realize the amount of education required for folks to understand how to do things in the cloud. I guess that is opportunity for guys like us, so I won’t cry too long… – MR Here we go again: There are a half dozen tokenization working groups proposing standards by my count. Each has vagueness baked into its published specification – many intentionally,

In the introduction to our series on Monitoring the Hybrid Cloud we went through all the disruptive forces which are increasingly complicating security monitoring. These include the accelerating move to cloud computing and expanding access via mobile devices. Those new models require much greater automation, and significantly less visibility and control over the physical layer of the technology stack. So you need to think about monitoring a bit differently. This starts with getting a handle on the nuances of monitoring, depending on where applications run, so we will discuss monitoring both IaaS (Infrastructure as a Service) and SaaS (Software as a Service). Not that we discriminate against PaaS (Platform as a Service), but it is similar enough to IaaS that the concepts presented are similar. We will also talk about private clouds because odds are you haven’t been able to unplug your data center, so you need to provide an end-to-end view of the infrastructure you use, including both technology you control (in your data center) and stuff you don’t (in the cloud). Monitoring IaaS The biggest and most obvious challenge in monitoring Infrastructure as a Service is the difference in visibility because you don’t control the physical stack. So you are largely restricted to logs provided by your cloud service provider. We see pretty good progress in the depth and granularity available from these cloud log feeds, but you still get much less detail than from devices in your data center. You also cannot tap the network to get actual traffic (packet capture). IaaS vendors offer abstracted networking so many networking features you have come to rely on aren’t available. Depending on the maturity of your security program and incident response process, you may not be doing much packet capture on your environment now, but either way it is no longer an option now in the cloud. We will go into more detail later in this series, but one workaround is to run all traffic through a cloud-based choke point for collection. In essence you perform a ‘man-in-the-middle’ attack on your own network traffic to regain a semblance of the visibility inside your own data center, but that sacrifices much of the architectural flexibility drawing you to the cloud in the first place. You also need to figure out where to both aggregate collected logs (both from the cloud service and from specific instances) and where to analyze them. These decisions hinge on a number of factors including where the technology stacks run, the kinds of analysis to perform, and what expertise is available on staff. We will tackle specific architectural options in our next post. Monitoring SaaS If monitoring IaaS offers a ‘foggy’ view compared to what you see in your own data center, Software as a Service is ‘dark’. You see what the SaaS provider shows you, and that’s it. You have access to neither the infrastructure running your application, nor the data stores that house your data. So what can you do? You can take solace in the fact that many larger SaaS vendors are starting to get the message from angry enterprise clients, and providing an activity feed you can pull into your security monitoring environment. It won’t provide visibility into the technology stack, but you will be able to track what your employees are doing within the service – including administrative changes, record modifications, and login history. Keep in mind that you will need to figure out thresholds and actions to alert on, mostly likely by taking a baseline of activity and then looking for anomalies. There are no out-of-the-box rules to monitor SaaS. And as with IaaS you need to figure out the best place to aggregate and analyze data. Monitoring a Private Cloud Private clouds virtualize your existing infrastructure in your own data center, so you get full visibility, right? Not exactly. You will be able to tap the network within the data center for additional visibility. But without proper access and instrumentation within your private cloud you cannot see what is happening within the virtualized environment. As with IaaS, you can route network traffic within your private cloud through an inspection point, but again that would reduce flexibility substantially. The good news is that many existing security monitoring platforms are rapidly adding the ability to monitor within virtual collection points which run in a variety of private cloud environments. We will address alternatives to extend your existing monitoring environment later in this series. SLAs are your friend As we teach in the CCSK (Certificate of Cloud Security Knowledge) course, you really don’t have much leverage to demand access to logs, events, or other telemetry in a cloud environment. So you will want to exercise whatever leverage you have during the procurement process; document specific logs, access, etc. in your agreements. You will find that some cloud providers (the smaller ones) are much more willing to be contractually flexible than the cloud gorillas. So you will need to decide whether the standard level of logging from the big guys is sufficient for the analysis you need. The key is that once you sign an agreement, what you get is what you get. You will be able to weigh in on product roadmaps and make feature requests, but you know how that goes. CloudSOC If a large fraction of your technology assets have moved into the cloud there is a final use case to consider: moving the collection, analysis, and presentation functions of your monitoring environment into the cloud as well. It may not make much sense to aggregate data from cloud-based resources, and then move the data to your on-premise environment for analysis. More to the point, it is cheaper and faster to keep logs and event data in low-cost cloud storage for future audits and forensic analysis. So you need to weigh the cost and latency of moving data to your in-house monitoring system against running monitoring and analytics in the cloud, in light of the varying pricing models for cloud-based

We continue to investigate the practical use of Threat Intelligence (TI) within your security program. After tackling how to Leverage Threat Intel in Security Monitoring, we now turn our attention to Incident Response and Management. In this paper we go deep into how your existing incident response and management processes can (and should) integrate adversary analysis and other threat intelligence sources, to help narrow down the scope of your investigations. We have also put together a snappy process map depicting how IR/M looks when you factor in external data. To really respond faster you need to streamline investigations and make the most of your resources. That starts with an understanding of what information would interest attackers. From there you can identify potential adversaries and gather threat intelligence to anticipate their targets and tactics. With that information you can protect yourself, monitor for indicators of compromise, and streamline your response when an attack is (inevitably) successful. You will have incidents. If you can respond to them faster and more effectively that’s a good thing, right? Integrating Threat Intel into the IR process is one way to do that. We’d like to thank Cisco and Bit9 + Carbon Black for licensing the content in this paper. We are grateful that our clients see the value of supporting objective research to educate the industry. Without forward-looking organizations you would be on your own… or paying up to get behind the paywall of big research. Check out the paper’s landing page, or download it directly: Leveraging Threat Intelligence in Incident Response/Management (PDF). Share: